FunnelFlux has two unique identifiers, which are detailed below.
Hit IDs
Hit IDs are generated for every view to a node by any visitor.
They are the most unique ID in our system. Every node visited (even rotators) generate a hit ID and these are the raw events we store in our analytics database. They can be passed in URL using the {hit} token.
Reporting
Hit IDs are only available on the raw events page
On the raw events page they are shown in the "Hit ID" column and are not available in regular reporting due to their high cardinality (i.e. our analytics database aggregating by these is a very non-performant query that should be avoided).
Note the raw events page only returns the most recent 1000 rows of any query -- to avoid the above performance issue.
When using the "visitor journey" reporting attribute, its these hit IDs that allow us to create a node-tree of user journey through funnels.
Conversion Tracking
The most common form of conversion tracking is to use a postback URL with our hit ID, viz:
https://USER_DOMAIN/pb/?hit=HIT_ID&rev=REVENUE&tx=OPTIONAL
The hit ID is generated on view of a page, so if redirecting to an offer, its the hit ID passed with {hit} in that offer URL that will represent the view to that page, and hence the ID to convert.
All offer hit IDs that are eligible to convert will end with an "h".
Conversions in JavaScript can specify a hit ID, which will be exact and no other data is needed. However, its unlikely that one would capture and push a correct hit ID into client-side JS as the hit to convert tends to be from the previous page.
If you can pass hits from one page to the next, you could probably just use a GET request to the postback URL, with that hit ID, to convert the hit rather than using JS.
Visitor IDs
These have the token {visitor} and are a session-level identifier for a user.
Our system will create these for any newly arriving visitor and automatically append &vid={visitor} to all redirection destinations, to ensure the resulting page (often a lander/offer with our JS on it) can seamlessly track the user.
Our cookie stores this VID value and it is the single most important value in ensuring reliable tracking of users. This is why our JS helper functions rewrite URLs to include it + inject it into action URLs.
Caching and Storage
The user session data is stored in a centralised cache that our regional edge servers access during redirect processing. The session object stores the entire history of the user's funnel navigation along with all URL parameters accompanying them from the traffic source, or that were manually injected into action/entrance URLs.
These Visitor IDs will be prefixed with an a, e or u for Asia, European and US-located visits, respectively. This allows other edges receiving an out-of-region ID to look it up from the correct cache, which is important in cases where a user may change location, use a VPN part way through a journey, or when third-party systems send server-side conversion events using the VID value.
Sessions have a default expiry of 7 days unless linked funnels are declared in funnel settings.
URL data
Notably, all URL data is stored in the session object, but only those named fields in the traffic source config will be committed to the analytics database. Thus, it is possible to pass temporary data into URLs and onward to pages/offers using this session object.
In the funnel builder > a page node > additional settings, the accumulated URL parameters toggle dumps this session object's URL data into the destination page URL.
Conversion Tracking
Conversions can be sent via our postback URL using both the visitor ID or hit ID.
Hit IDs are the most specific ID in our system and reference a specific view to a specific node by a single visitor -- thus only the hit ID is needed.
For visitor ID, the page they viewed is also important information, since the visitor ID only identifies the user session, not what offer to convert.
Thus this will work as a postback URL:
https://USER_DOMAIN/pb/?vid=VISITOR_ID&p=PAGE_ID&rev=REVENUE&tx=OPTIONAL
If no page ID is provided, the most recent offer view for that visitor will be converted (which may not be the desired result).
Conversions in JavaScript ideally also include vid in their code since the JS ultimately relies on coherent VID tracking.
This can be manually injected, although the JS will readily obtain this information from the current URL, cookie and referrer, if available. If it can be dynamically injected, it is best to do so.
If the VID is used, it is also ideal to push the page ID (the p attributed), and avoid sending hit ID in combination with VID as they are competing methods, the latter being more specific.
Reporting
On the raw events page they are shown in the "session ID" column and are not available in regular reporting due to their high cardinality (i.e. our analytics database aggregating by these is a very non-performant query that should be avoided)
Linked funnels and indirect conversions
One feature of FunnelFlux is the ability to attribute revenue/conversions indirectly to a previous funnel.
This is accomplished by the first funnel declaring the second funnel as a "linked funnel" in its advanced settings.
When linked funnels are present, the session expiry time is extended to 30 days.
When a conversion happens in funnel B, the conversion processor will inspect the user's session data, see the original funnel A that has been "linked" to funnel B, and will additionally pass back an indirect conversion.
This conversion/revenue data is viewable in reporting and allows users to see the extended value of users coming from later funnels.
A good example is an opt-in funnel, where users are tracking the cost of leads from an ad campaign. That funnel may link to an email funnel, where a user is generating links to use in email sequences. The emails may create conversions, which track independently within the email funnel, but also notify the original opt-in funnel of indirect revenue it created.
For this feature to work, the VID value of the user MUST be passed into the entrance URLs used in funnel B. Usually by manually appending something like ..&vid=%SUBSCRIBER_FF_VID% to a URL, where the user captured our VID during opt-in and stored it on some CRM profile attribute.